home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1105 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.6 KB
  1. From: S.D.Maclean@ecs.soton.ac.uk (Stuart Maclean)
  2. Message-ID: <sdm-1604961139410001@galois.ecs.soton.ac.uk>
  3. X-Original-Date: Tue, 16 Apr 1996 11:39:41 +0000
  4. Path: in2.uu.net!bounce-back
  5. Date: 16 Apr 96 12:27:03 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: IOSTREAM question : should ends manipulator flush buffer?
  9. Organization: University of Southampton
  10. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  11.     iQBFAgUBMXOSKeEDnX0m9pzZAQHUQwF+Piwoee2lCYjpl5F0BHol2Dtc+eX5yFsW
  12.     +8nUsbKSPEjY6NFn11Eybxo2/YBnr7OQ
  13.     =jBmk
  14.  
  15. Hi, I'm currently implementing a stream class where the external
  16. representation is a socket.  Whilst playing with the following
  17.  
  18. TCPSocket tcp;
  19. ....
  20. Sockstream  ss( tcp );
  21.  
  22. ss << "Hello World!" << endl;
  23. ss << "Hello World!" << ends;
  24.  
  25. I noticed that manipulator "endl" synchronises with the external
  26. representation, but "ends" does not.  Tracing our IOStream library,
  27. libg++-2.7.1, it indeed does not do a flush when using "ends".  In C++PL2
  28. by Stroustrup, page 348 has a comment implying that "ends" should do a
  29. flush.
  30.  
  31. Does anyone know the correct behaviour for "ends" in the Standard C++
  32. Library, whatever that is and whenever it may appear 8-)
  33.  
  34. Any help gratefully appreciated.
  35.  
  36. Stuart
  37.  
  38. -- 
  39. Stuart
  40. ---
  41. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  42. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  43. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  44. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  45. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  46.